Thanks!

Hi @gschuurman. It is exciting to see we are trying to use the new and better Neo4j chart! But since the PR introduces Neo4j 5.x, have you tested if it works well compatibly with the current DataHub (which has been using Neo4j 4.x)?

@lix-mms I've tested the entire datahub application, and have been running it in production for a couple of weeks. Didn't experience any issues. I also cross validated the used clients in the datahub application. Fortunatly they use a LTS version, which supports multiple versions, including version Neo4J 4.x and 5.x..

@gschuurman Thanks for the reply! Great to hear that!

Btw, when you use this new Helm chart to deploy the prerequisites, have you experienced that the stateful set for the community and the enterprise are both created, even when we set the edition to "community" in the values?

(Following pic shows that after my helm install run, both the community pod and the enterprise pods (core+replica) are appearing)

@lix-mms Well, that's one of the reasons I marked it as a breaking change. I would have thought that would also enter into the release notes.
It seems to me that you're still deploying the old version of the pre-requisites chart, please do a helm repo update
This will fetch all the latest charts from the internet, and then do a helm list to see which chart versions are installed. In my case it's the following:

NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
datahub         datahub         5               2023-10-05 07:30:12.116833895 +0000 UTC deployed        datahub-0.3.1                   0.11.0
prerequisites   datahub         10              2023-10-05 07:30:03.905324593 +0000 UTC deployed        datahub-prerequisites-0.1.1

Also please make sure that you update your values file to represent the current state.

It might also be possible that the old objects are still existing.
I have the following statefull sets in the selected namespace:

elasticsearch-master      1/1     23d   elasticsearch   docker.elastic.co/elasticsearch/elasticsearch:7.17.3
prerequisites-kafka       1/1     23d   kafka           docker.io/bitnami/kafka:3.4.0-debian-11-r33
prerequisites-mysql       1/1     23d   mysql           docker.io/bitnami/mysql:8.0.29-debian-11-r3
prerequisites-neo4j       1/1     23d   neo4j           neo4j:5.11.0
prerequisites-zookeeper   1/1     23d   zookeeper       docker.io/bitnami/zookeeper:3.8.1-debian-11-r31

As a last piece of advice, deploy your datahub in a separate namespace, this helps to keep your kubernetes cluster more isolated since connections between namespaces are normally not allowed by default. You can do so by specifying the namespace in the helm command using --namespace {namespace_name} --create-namespace

@gschuurman You are completely right! I installed from the datahub-helm repo directly and didn't realise that I needed to rebuild the dependency from here too. After the rebuild, the installation could continue.

Although when providing custom secret for the password, I was asked by Helm to ensure the NEO4J_AUTH exists in the secret and starts with "neo4j" with the following message:

Error: UPGRADE FAILED: execution error at (datahub-prerequisites/charts/neo4j/templates/_helpers.tpl:351:19): Password in secret neo4j-secrets-new must start with the characters 'neo4j/'

which was not quite intuitive since I expected we might be able to determine for our own root user name. But it is not a show stopper anyway. After the corresponding adjustment, the installation was finally successful with just one community pod.

Thank you very much for all the tips! 🙏

Btw the document line mentioning the NEO4J_AUTH entry could say that it is expected to be in the secret data rather than in the values yaml so it is a bit more clear to understand. But that's for sure a minor thing. 🙂